Development - Introduction
An Introduction to PDXMC for potential future developers. This clinic will discuss the basics for if you're just starting and things to look out for. This is ***NOT*** a complete guide and is just intended as an introductory stage. Introduction Assuming you were hand-picked by the developers, or you came across the Devkit Archive, here's what you need to do. Unzip the archive, it should be a large folder. Inside you'll find the following: * Server Master Folder (includes frontend, plugins, config files, etc.) * Various readmes * Changelog to add additions to * PortlandMC Master Map File * Heightmap, as well as outline plan * Downloaders for various tools This is all required to start working. As for getting the server up and running, you don't necessarily have to port-forward if you're working alone. However if you plan to make the server open and have other people helping, port forward your default gateway and allow the 25565 port on TCP/UDP. (Note: check router settings for this.) Once you've port forwarded start the run.bat file. It should start up normally and without issues. Check your server.properties file and make sure the server-ip is BLANK. Port listed should be 25565. NOTE: Spigot API is used for server frontend. After that, connect in-game and get to work. Muscle Memory, & Adopting Good Habits TBD (discuss hotkeys, macros, goal-planning) Staying Motivated TBD (discuss motivation) What do I do if...? Let's go over a few potential problems you might encounter. Q/A Q: My co-developers are losing steam/aren't working/aren't interested/won't bother helping anymore. Any ideas? A: There's a few solutions to this. You may want to give them space, see if they return, or try to work things out as a group in a group chat meeting. # Get all devs together in a group chat, discuss how to fix this and what can be done to solve the problem. # Give them space. Sometimes they're just burnt out, and the best way to fix this is to give them space and time. They will (probably) return soon. # Accept it and move on. There is no contractual agreement; everyone is working on their own volition and time. Pick developers carefully. Q: Server's not working. Is it an API issue, or is Java acting dodgy? A: Check if there's an update to your Java client, or check if there's an API update. Usually, the server log will tell you at the very top, "Outdated Build" or something similar. This is a sign that you need to update. You WON'T WANT TO UPDATE JAVA VERY FREQUENTLY AS IT MAY BREAK YOUR SERVER OR OTHER PROGRAMS. ENSURE COMPATIBILITY FIRST! TBD (add more Q/As) Releasing Updates Updates should only be released when a substantial gap in development and time has been reached. Yearly, or bi-quarterly updates are usually best. For smaller, mini-updates - release every 3 months. Releasing The Update If new visitors are expected, get the server ready to run for a while. This "hot" period usually lasts less than a week or two. The first 5 days are critical for retaining interest. Setting Goals & Dev Efficiency Assign projects to dev members. Example: * Dev #1 - Assigned to revit Park Blocks * Dev #2 - Assigned to rebuild Big Pink. * Dev #3 - Touch up waterfront, add extra detail... * Dev #4 - Start early foundation work on the Airport. This ensures there is a clear goal to work towards and the work is spread out efficiently across the team. How do I maximize output and time management? Working session ideally should be done in short intervals, with frequent breaks. Example: * Dev #4 - Start early foundation work on the Airport. # Lay foundation. Time estimate: 30m - afterwards, work on something else. * Dev #1 - Assigned to revit Park Blocks # Touch up X block. Afterwards, work on the rest of the foundation for the Airport, picking up Dev #4's slack. * Dev #4 - Finalize Dev #1's workflow, taking turns rotating shifts. This ensures everyone has something to do and isn't left bored. This also maximizes the workflow output, ensuring everyone works on something evenly and at their own pace. If a dev gets bored of a project, return them to project assignment to work on something else, or let them take a break for a while. Once they come back, re-assign them to finish their assigned project for the day/week. This Theory in Practice (PDXMC Original Workflow) As of writing this, I have not implemented this system yet. Currently it's a base to work from, to hopefully increase our productivity. However, keep in mind this system only works if your dev team is online consistently. Many of the devs now are on at different times and uncooperative - this is best used with a professionally-coordinated team. What Our System Is We don't have a system. Someone works on something when they're online until they get tired of it, then they either work on something else or take a break. Note that we're not using the Slack system. I hope to implement something once everyone can work more often, but I'm not that hopeful.__NOEDITSECTION__ Category:Development